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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document specifies the interface and protocol for simple wireless communication between close coupled 
devices. These Near Field Communication (NFC) devices communicate with transfer rates of 106 kbps , 212 kbps and 
424 kbps. 

The present document allows, but does not specify, applications in network products and consumer equipment. 
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Scope 



The present document defines communication modes for Near Field Communication Interface and Protocol (NFCIP-1) 
using inductive coupled devices operating at the centre frequency of 13,56 MHz for interconnection of computer 
peripherals. It also defines both the Active and the Passive communication modes of Near Field Communication 
Interface and Protocol (NFCIP-1) to realize a communication network using Near Field Communication devices for 
networked products and also for consumer equipment. The present document specifies, in particular, modulation 
schemes, codings, transfer speeds, and frame format of the RF interface, as well as initialization schemes and conditions 
required for data collision control during initialization. Furthermore, the present document defines a transport protocol 
including protocol activation and data exchange methods. 

Information interchange between systems also requires, at a minimum, agreement between the interchange parties upon 
the interchange codes and the data structure. 



Conformance 



A system implementing the Active and the Passive communication mode shall be in conformance with the present 
document if it meets all the mandatory requirements specified herein. 



References 



The following standards contain provisions which, through reference in this text, constitute provisions of the present 
document. All standards are subject to revision, and parties to agreements based on the present document are 
encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

ITU-T Recommendation V.41 (1988): "Code-independent error-control system". 



4 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

4.1 Active communication mode 

Both the Initiator and the Target use their own RF field to enable the communication. This is the scheme of the Active 
communication mode. 

4.2 ASK modulation 

ASK stands for Amplitude Shift Keying. The amplitude of the carrier frequency is modulated according to the logic of 
the data to be transmitted. The degree of modulation is expressed by (a - b)l{a + b)x 100 [%], where a and b 
respectively represent the maximum and minimum amplitudes of the modulated signal waveform. 



4.3 Binary Coded Decimal (BCD) 



A system for representing each of the decimal numbers to 9 by a four-bit binary code. The bits, from left to right, are 
worth 8, 4, 2 and 1 respectively in decimal, so for example the number 6 in BCD is 01 10. 
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4.4 Collision 



Transmission by two or more Targets or Initiators during the same time period, such that the Initiator or the Target is 
unable to distinguish from which Target the data originated. 

4.5 Frame 

Sequence of data bits and optional error detection bits, with frame delimiters at start and end. 

4.6 Initiator 

Generates the RF field and starts the NFCIP-1 communication. 

4.7 Load modulation 

Process of amplitude modulating a radio frequency field by varying the properties of a resonant circuit placed within the 
radio frequency field. 

4.8 Isb first 

least significant bit first. Indicates a serial data transmission system that sends Isb before all other bits. 

4.9 LSB first 

Least Significant Byte first. Indicates a serial data transmission system that sends LSB before all other bytes. 



4.10 Manchester coding 



Method of bit coding whereby a logic level during a bit duration is represented by a sequence of two defined physical 
states of a communication medium. The order of the physical states within the sequence defines the logical state. 

The coding system which divides into half at the changing point in the middle point of bit self-sustaining time, and 
makes the direction of the changes correspond to two logic value. 

4.11 Modulation index 

Defined as (a - b)l(a + b) where a and b are the peak and the minimum signal amplitude respectively with the value of 
the index possibly expressed as a percentage. When the maximum amplitude of the modulated signal waveform is set to 
a and the minimum value is set to b, the degree of abnormal conditions is usually expressed as a percent. 

4.12 msb first 

most significant bit. Indicates a serial data transmission system that sends the msb before all other bits. 

4.13 MSB first 

Most Significant Byte. Indicates a serial data transmission system that sends the MSB before all other bytes. 

4.14 NFCIP-1 device 

General term for either an Initiator or a Target communicating in the Active or the Passive communication mode. 
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4.15 NFCIDentifier(NFCIDA?) 



NFCIDn is a randomly generated number used by the RF Collision Avoidance and Single Device Detection sequence 
for both the Active and the Passive communication modes. 

4.16 Passive communication mode 

The Initiator is generating the RF field and the Target responds to an Initiator command in a load modulation scheme. 



4.17 RF Collision Avoidance (RFCA) 



Method to detect the presence of a RF field based on the carrier frequency and method to detect and resolve collisions 
on protocol level. 

4.18 SEL_PAR 

Total number of valid bits of NFCIDl CL« including SEL_CMD and SEL_PAR transmitted by the Initiator. 

4.19 Sensing 

An NFCIP-1 device in the Active communication mode expects a Response to a Request it has sent on the RF field to 
detect the start of communication to receive the Request. 

4.20 Single Device Detection (SDD) 

SDD is an algorithm used by the initiator to detect one out of several Targets in its RF field. 

4.21 Subcarrier 

Signal of frequency fs used to modulate a carrier of frequency fc. 

4.22 Target 

Target responds to Initiator command either using load modulation scheme (RF field generated by Initiator) or using 
modulation of self generated RF field. 

4.23 Time Period 

The Time Period defines the number of slots used for RF Collision Avoidance. 

4.24 Time Slot 

Method of preparing a time window when a Target answers, and assign and identify two or more logic channels. 

4.25 transaction 

A transaction includes the initialization and the transparent data exchange between an Initiator and a Target either in the 
Active or the Passive communication mode. 
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5 Conventions and notations 

5.1 Representation of numbers 

The following conventions and notations apply in the present document unless otherwise stated. 
Letters and digits in parentheses represent numbers in hexadecimal notation. 
The setting of bits is denoted by ZERO or ONE. 



• 



• 



• Numbers in binary notation and bit patterns are represented by strings of digits and 1 shown with the most 
significant bit to the left. Within such strings, X may be used to indicate that the setting of a bit is not specified 
within the string. 

5.2 Names 

The names of basic elements, e.g. specific fields, are written with a capital initial letter. 



Acronyms 



ALL_REQ Wake up ALL Request 

ASK Amplitude Shift Keying 

ATR Attribute Request and Attribute Response 

ATR_REQ Attribute Request 

ATR_RES Attribute Response 

BCC NFCIDl CL« check byte, calculated as exclusive-or over the 4 previous bytes 

BCD Binary Coded Decimal 

bd Bit duration 

BRi Receiving bit duration supported by Initiator 

BRt Receiving bit duration supported by Target 

BSi Sending bit duration supported by Initiator 

BSt Sending bit duration supported by Target 

CLn Cascade Level n, 3 > « > 1 

CMD Command 

CRC Cyclic Redundancy Check 

CT Cascade Tag 

D Divisor 

DEP Data Exchange Protocol Request and Data Exchange Protocol Response 

DEP_REQ Data Exchange Protocol Request 

DEP_RES Data Exchange Protocol Response 

DIDi Initiator Device ID 

DIDt Target Device ID 

DRi Data rate Received by initiator 

DRt Data rate Received by target 

DSi Data rate Send by initiator 

DSL Deselect Request and Deselect Response 

DSL_REQ Deselect Request 

DSL_RES Deselect Response 

DSt Data rate Send by Target 

fc Frequency of operating field (carrier frequency) 

fd Baseband frequency of Manchester coding 

FRT Frame Response Time 

fs Frequency of subcarrier (fc/16) 

Gi Optional information field for Initiator 

Gt Optional information field for Target 

ID Identification number 

Isb least significant bit 
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LSB Least Significant Byte 

MI Multiple Information link for Data Exchange Protocol 

msb most significant bit 

MSB Most Significant Byte 

NAD Node Address 

NFCIDl Random Identifier for single device detection in the Passive communication mode at 106 kbps 

nfcidln Byte number n of NFCIDl 

NFCID2 Random ID for SDD in the Passive communication mode at 212 kbps and 424 kbps 

nfcid2n Byte number n of the Random Identifier NFCID2 

NFCID3 Random ID for transport protocol activation 

nfcidSn Byte number n of the Random Identifier NFCID3 

P Odd parity bit 

PA Preamble 

pdu protocol data unit 

PFB Control information for transaction 

PNI Packet Number Information 

PPi Protocol Parameters used by Initiator 

PPt Protocol Parameters used by Target 

PSL Parameter Selection Request and Parameter Selection Response 

PSL_REQ Parameter Selection Request 

PSL_RES Parameter Selection Response 

RF Radio Frequency 

RFCA RF Collision Avoidance 

RFU Reserved for Future Use 

RLS Release Request and Release Response 

RLS_REQ Release Request 

RLS_RES Release Response 

RWT Response Waiting Time 

SB Start byte for data exchange protocol at 106 kbps 

SDD Single Device Detection 

SDD_REQ Single Device Detection Request command 

SEL_CMD Select Command byte 

SEL_PAR Select Parameter byte 

SEL_REQ Select Request command 

SENS_REQ Sense Request command 

SENS_RES Sense Response command 

SLP_REQ Sleep Request command 

SYNC Synchronous pattern 

TO Timeout value 

WT Waiting Time 

WUP Wakeup Request and Wakeup Response 

WUP_REQ Wakeup Request 

WUP_RES Wakeup Response 
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General 



The present document defines both the Active and the Passive communication modes as follows: 

In the Active communication mode, both the Initiator and the Target shall use their own RF field to enable 
communication. The Initiator starts the NFCIP-1 communication. The Target responds to an Initiator command in the 
Active communication mode using self-generated modulation of self-generated the RF field. 

In the Passive communication mode, the Initiator generates the RF field and starts the communication. The Target 
responds to an Initiator command in the Passive communication mode using a load modulation scheme. 

The communication over the RF interface in the Active and the Passive communication mode shall include modulation 
schemes, transfer speed and bit coding. In addition it shall include the start of communication, the end of 
communication, the bit and byte representation, the framing and error detection, the single device detection, the 
protocol and parameter selection and the data exchange and de-selection of Near Field Communication Interface and 
Protocol (NFCIP-1) devices. 
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All NFCIP-1 devices shall have communication capability on 106 kbps and may switch to another transfer speed or stay 
at 106 kbps. All NFCIP-1 devices shall have communication capability on 212 kbps and may switch to another transfer 
speed or stay at 212 kbps. All NFCIP-1 devices shall have communication capabilities on 424 kbps and may switch to 
another transfer speed or stay at 424 kbps. 

The mode (Active or Passive) shall not be changed during one transaction until the deactivation of the Target or 
removal of the Target, even though the transfer speed of Initiator to Target and the transfer speed of the Target to the 
Initiator may not be the same. The change of transfer speed during one transaction may be performed by a parameter 
change procedure. 

The transaction is started by device initialization and terminated by device de-selection (or equivalent). 
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RF field 



The carrier frequency of the RF field shall be 13,56 MHz. 

The minimum unmodulated RF field shall be Hj^^j^ and has a value of 1,5 A/m rms. 

The maximum unmodulated RF field shall be H„,.„ and has a value of 7,5 A/m rms. 

IIldA ' 

This field shall be modulated during communication. 



8.1 



Passive Communication IVIode 



An Initiator shall produce a RF field to energize the target. 
A Target shall operate continuously between H • and H 



8.2 



Active Communication IVIode 



An Initiator and a Target shall alternately generate a RF field of at least H^^^j^ and not exceeding Hj^^^^ at manufacturer 
specified positions (operating volume). 



RF Signal Interface 



9.1 



Bit duration 



The bit duration bd is calculated by the following formula: 

lM=128/(Dxfc) 

The values of the divisor D depend on the bit rate and are given by table 1 . The fc is the carrier frequency as defined in 
clause 8. 

Table 1 : Definition of Divisor D 



Communication IVIode 


kbps 


Divisor D 


active or passive 


106 


1 


active or passive 


212 


2 


active or passive 


424 


4 


Active 


848 


8 


Active 


1 667 


16 


Active 


3 390 


32 


Active 


6 670 


64 
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NOTE: The Initiator for starting the communication chooses the initial bit rate. 

9.2 Active communication mode 

The specification of both from the Initiator to the Target and from the Target to the Initiator shall be identical. 

9.2.1 106 kbps 

9.2.1.1 Bit rate 

The bit rate for the transmission during initialization and single device detection shall be fc/128 (106 kbps). 

9.2.1.2 Modulation 

Communication from the Initiator to a Target and a Target to the Initiator for a bit rate of fc/128 shall use the 
modulation principle of ASK 100 % of the RF operating field to create a "Pulse" as shown in figure 1. 

The envelope of the field shall decrease monotonically to less than 5 % of its initial value Hjj^jjj^l ^^d remain less than 
5 % for more than t2. (See table 2). This envelope shall comply with figure 1. 

If the envelope of the field does not decrease monotonically, the time between a local maximum and the time of passing 
the same value before the local maximum shall not exceed 0,5 )is. This shall only apply if the local maximum is greater 
than5%ofHjNjTiAL- 

Overshoots shall remain within 90 % and 110 % of Hjjs^jjj^l- 

The Target shall detect the "End of Pulse" after the field exceeds 5 % of Hjj,^jjj^l ^"d before it exceeds 60 % of 
^INITIAL- Th^ "End of Pulse" is defined by t4 in table 2. This definition applies to all modulation envelope timings. 

Envelope of carrier amplitude 
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Figure 1 : Pulse shape 
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Table 2: Pulse shape value 



Pulses length 


t1 [|iS] 


t2 [us] 


t3 l\is] 


t4 [us] 


(Condition) 




(t1<2,5) (t1>2,5) 






T max 


3,0 


t1 


1,5 


0,4 


T min 


2,0 


0,7 0,5 


0,0 


0,0 



9.2.1 .3 Bit representation and coding 

The following coding shall be used: 

• Start of communication: at the beginning of the bit duration a "Pulse" shall occur. 

• ONE: after a time of half the bit duration a "Pulse" shall occur. 

• ZERO: For the full bit duration no modulation shall occur with the following two exceptions: 

If there are two or more contiguous ZEROs, from the second ZERO on a Pulse shall occur at the 
beginning of the bit duration. 

If the first bit after a "start of communication" is ZERO, a "Pulse" shall occur at the beginning of the bit 
duration. 

• End of Communication: ZERO followed by one bit duration without modulation. 

• No information: shall be coded with at least two full bit duration without modulation. 



9.2.1 .4 Byte encoding 

The byte encoding shall be least significant bit (Isb) first. 

9.2.2 21 2 kbps and 424 kbps 



9.2.2.1 



Bit rate 



The bit rates for the transmission during initialization and single device detection shall respectively be fc/64 (212 kbps) 
or fc/32 (424 kbps). 



9.2.2.2 



Modulation 



The Initiator shall use the modulation of ASK with the modulation index of 8 % to 30 % of the operating field. The 
modulation waveform shall comply with figure 2. The rising and falling edges of the modulation shall be monotonic. 
The modulation for the transmission during initialization and single device detection shall be the same, a and b define 
the peak and the minimum signal amplitude. See 4.11. 

Table 3: Modulated waveform 





212 kbps 


424 kbps 


tf 


2,0 us max 


1 ,0 us max 


tr 


2,0 us max 


1 ,0 us max 


y 


0,1 {a-b) 


0,1 (a-b) 


hf, hr 


0,1 (a- b) max 


0,1 (a- b) max 
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nk^u^^^-^' 



tf 



b 



tr 



hf 



^^ ^^ 



Figure 2: Modulated Waveform 



hr 



9.2.2.3 Bit representation and coding 

Manchester bit encoding shall be employed. The waveform is shown in figures 3 and 4. Bit coding format is 
Manchester with logic levels defined as: 

Logic "ZERO": The first half of a bit is carrier low field amplitude, and the second half of the bit shall be carrier high 
field amplitude (no modulation applied). 

Logic "ONE": The first half of a bit is carrier high field amplitude (no modulation applied), and the second half of the 
bit shall be carrier low field amplitude. 

Reverse polarity in amplitude shall be permitted. Polarity shall be detected from the SYNC. 



, 1bit , 



, 1bit , 



^♦- 



-^ 



^♦- 



-^ 



ZERO I I ONE 

Figure 3: IVIanchiester bit encoding (obverse amplitude) 



1 bit 



1 bit 



-^ 



u*- 



-^ 



ONE 



ZERO 



Figure 4: Manchester bit encoding (reverse amplitude) 



9.2.2.4 Byte encoding 

The byte encoding shall be most significant bit (msb) first. 
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9.3 Passive communication mode 

9.3.1 1 06 kbps Initiator to Target 

9.3.1.1 Bit rate 

The bit rate for transmission during initialization and single device detection from the Initiator to the Target in the 
Passive communication mode shall be the same as the bit rate for communication from Initiator to the Target in the 
Active communication mode. See 9.2.1.1. 

9.3.1.2 Modulation 

The modulation for transmission during initialization and single device detection from the Initiator to the Target in the 
Passive communication mode shall be the same as the modulation for communication from Initiator to the Target in the 
Active communication mode. See 9.2.1.2. 

9.3.1 .3 Bit representation and coding 

The bit representation and coding for the transmission during initialization and single device detection from the Initiator 
to the Target in the Passive communication mode shall be the same as the bit representation and coding for 
communication from Initiator to the Target in the Active communication mode. See 9.2.1.3. 

9.3.1.4 Byte encoding 

The byte encoding shall be least significant bit (Isb) first. See 9.2.1.4. 

9.3.2 1 06 kbps Target to Initiator 

9.3.2.1 Bit rate 

The bit rate for the transmission during initialization and single device detection shall be fc/128. 

9.3.2.2 Modulation 

The Target shall respond to the Initiator via an inductive coupling area where the carrier frequency is loaded to generate 
a subcarrier with frequency fs. The subcarrier shall be generated by switching a load in the Target. 

The load modulation amplitude shall be at least 30/H''^ (mV peak) where H is the (rms) value of magnetic field 
strength in A/m. 

9.3.2.3 Subcarrier Frequency 

The frequency fs of the subcarrier shall be fc/16. 

9.3.2.4 Subcarrier modulation 

Every bit period shall start with a defined phase relation to the subcarrier. The bit period shall start with the loaded state 
of the subcarrier. 

The subcarrier shall be modulated with the sequences defined in clause 9.3.2.5. 

9.3.2.5 Bit representation and coding 

The Bit representation and coding is defined in clause 9.2.2.3 and shown in figure 3 Manchester Coding with obverse 
amplitude. Reverse polarity in amplitude shall be not allowed. 
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9.3.2.6 Byte encoding 

The byte encoding shall be least significant bit (Isb) first. 

9.3.3 21 2 kbps and 424 kbps Initiator to Target 

9.3.3.1 Bit rate 

The bit rate for transmission during initialization and single device detection from the Initiator to the Target in the 
Passive communication mode shall be the same as the bit rate for communication from Initiator to the Target in the 
Active communication mode. See 9.2.2.1. 

9.3.3.2 IVIodulation 

The modulation for transmission during initialization and single device detection from the Initiator to the Target in the 
Passive communication mode shall be the same as the modulation for communication from Initiator to the Target in the 
Active communication mode. See 9.2.2.2. 

9.3.3.3 Bit representation and coding 

The bit representation and coding for the transmission during initialization and single device detection from the Initiator 
to the Target in the Passive communication mode shall be the same as the bit representation and coding for 
communication from Initiator to the Target in the Active communication mode. See 9.2.2.3. 

9.3.3.4 Byte encoding 

The byte encoding is defined in clause 9.2.2.4. 

9.3.4 21 2 kbps and 424 kbps Target to Initiator 

9.3.4.1 Bit rate 

The bit rate for transmission during initialization and single device detection from the Initiator to the Target in the 
Passive communication mode shall be the same as the bit rate for communication from Initiator to the Target in the 
Active communication mode. See 9.2.2.1. 

9.3.4.2 Modulation 

The Target shall be capable of communication to the Initiator via an inductive coupling area where the carrier frequency 
is loaded to generate a Manchester coding with bit duration bd. (See 9.2). The Manchester coding shall be generated by 
switching a load in the Target. 

The load modulation amplitude shall be at least 30/H''^ (mV peak) where H is the (rms) value of magnetic field 
strength in A/m. 

9.3.4.3 Bit representation and coding 

The bit representation and coding for the transmission during initialization and single device detection from the Initiator 
to the Target in the Passive communication mode shall be the same as the bit representation and coding for 
communication from Initiator to the Target in the Active communication mode. See 9.2.2.3. 

9.3.4.4 Byte encoding 

The byte encoding is defined in clause 9.2.2.4. 
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10 General Protocol flow 



The General Protocol flow between NFCIP-1 devices shall be conducted through the following consecutive operations: 

Any NFCIP-1 device shall per default be in Target mode. 

When in Target mode, it shall not generate an RF field, and shall wait silently for a command from the 
Initiator. 

The NFCIP-I device may switch to Initiator mode only if required by the application. 

The application shall determine either Active or Passive communication mode and transfer speed. 

Initiator shall test for external RF field present and shall not activate its RF field if an external RF field is 
detected. 

If an external RF field is not detected, the Initiator shall activate its RF field. 

The Target shall be activated by the RF field of the Initiator. 

Transmission of a command by the Initiator either in the Active communication mode or in the Passive 
communication mode at a selected transfer speed. 

Transmission of a response by the Target either in the Active communication mode or in the Passive 
communication mode. The communication mode and the transfer speed shall be the same as the Initiator 
communication mode and the transfer speed. 

Figure 5 shows the general initialization and single device detection flow for the Active and the Passive communication 
mode at different transfer speeds. 

The General Protocol flow describes the flow to initialize and select the Targets either in the Passive communication 
mode or in the Active communication mode using one of the chosen transfer speeds. RF Collision Avoidance is 
described in clause 11.1. Passive communication mode is described in clause 11. 2. The initialization and SDD for 
106 kbps is described in clause 1 1.2.1, initialization and SDD for 212 kbps and 424 kbps is described in clause 1 1.2.2. 
The Active communication mode is described in clause 1 1.3. 

The Activation of the Protocol is described in clause 12.5. The Parameter Selection is described in clause 12.5.3. The 
Data Exchange Protocol is described in clause 12.6. The Deactivation is described in clause 12.7. 
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Initial RF Collision 
Avoidance 




Application switches to 
initiator mode for Passive 
communication mode and 
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and performs the initialisation 
and the SDD 



Application switches to 
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communication mode 
and chooses transfer 
speed 



Activation in Passive 
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byNFClD3(ATR) 



Activation in Active 
communication mode 
byNFCID3(ATR) 
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Protocol 
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Data exchange protocol 
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Data 

Exchange 

Protocol 



De- 

Activatior 
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Figure 5: General initialization and single device detection flow 



11 



Initialization 



This clause describes the initialization and colhsion detection protocol for Targets in the Active and the Passive 
communication mode. The Initiator shall detect a collision that occurs, when at least two Targets simultaneously 
transmit bit patterns with one or more bit positions where they transmit complementary values. 

Figure 5 shows the general initialization and Single Device Detection flow for the Active and the Passive 
communication mode at different transfer speeds. 

11.1 RF Collision Avoidance 

In order not to disturb any other NFC communication and any current infrastructure running on the carrier frequency, an 
Initiator for NFC communication shall not generate its own RF field as long as another RF field is detected. 
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11.1.1 Initial RF Collision Avoidance 

To start communication with the Target device either in the Active or the Passive communication mode an Initiator 
shall sense continuously for the presence of an external RF field. 

If the Initiator detects no RF field within the timeframe Tj£,j + « x Tj^p^y the RF field shall switch on. The integer value 
of n is randomly generated. Figure 6 illustrates the initial RF Collision Avoidance during initialization. 



RFOn 



Send Request 



Start 



^IDT- 



^RFW- 



^IRFG- 



TiRFG 



n X Trfw 



Figure 6: Initial RF Collision Avoidance 

Initial delay time. Tj^^p > 4 096/fc 

RF waiting time. 512/fc 

randomly generated number of Time Periods for Tjjpyy 

< n < 3 

Initial guard-time between switching on RF field and start to send command or data frame 

TiRFG > 5 ms 



The RF field, which is generated by the Initiator, shall be switched off in the Active communication mode. The RF 
field, which is generated by the Initiator, shall not be switched off in the Passive communication mode. 



1 1 .1 .2 Response RF Collision Avoidance 



In addition to the initial RF Collision Avoidance as described in clause 11.1.1. A response RF collision avoidance 
during activation shall be required in the Active communication mode to avoid collision of data by simultaneous 
responding of more than one target. Figure 7 illustrates the response RF Collision Avoidance sequence during 
initialization. 



RFOn 



Send Response 



Start 



Tadt 



n X Tr 



Figure 7: Response RF Collision Avoidance sequence during activation 
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T^j-j-p: Active delay time, sense time between RF off Initiator/Target and Target/Initiator 

(768/fc<T^x^2 559/fc) 
Tjjpyy: RF waiting time (51 2/fc) 

n: Randomly generated number of Time Periods for Tj^p^y (0 < n < 3) 

^ARFG' Active guard time between switching on RF field and start to send command (T^^^pQ > 1 024/fc) 

1 1 .2 Passive communication mode 

11 .2.1 Initialization and Single Device Detection at 1 06 kbps 

11.2.1.1 Frame format and timing 

This clause defines the frame format and timing used during initialization and Single Device Detection in passive 
communication mode at 106 kbps. For bit representation and coding. See 9.3.1.3. 

Before the communication starts the initiator has to perform the initial RF Collision Avoidance as described in 
clause 11.1.1. 

Data Frames shall be transferred in pairs, the Initiator initiates the communication followed by the response of the 
Target. 

The Initiator Frame format includes the start of communication, the information and the end of communication. 
See table 4. 

Table 4: Initiator Frame format 



Start of communication 
(Start) 


Information 


End of communication (End) 



Frame Response time between Initiator and Target. 

The Target frame format includes the start of communication, the information and the end of communication. 
See table 5. 

Table 5: Target Frame format 



Start of communication 
(Start) 


Information 


End of communication (End) 



Frame Response time Target to Initiator. 
The Frame Response time (FRT) from Target to Initiator overlaps the Initiator end of communication. 

1 1 .2.1 .2 Frame Response Time Initiator to Target 

The Frame Response Time is the time between the end of the last pulse transmitted by the Initiator and the first 
modulation edge within the start bit transmitted by the Target table 6 defines values for n and FRT depending on the 
command type and the logic state of the last transmitted data bit in this command. 
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Table 6: Frame Response Time (Initiator to Target) 



Command type 


n (integer value) 


FRT 1 






last pulsed bit = ONE 


last pulsed bit = ZERO 


SENS REQ 
ALL REQ 
SDD REQ 
SEL REQ 


9 


(nx128 + 84)/fc 


(nx128 + 20)/fc 


All other commands 


>9 



The value « = 9 means that all Targets in the field shall respond in a synchronous way which is needed for Single 
Device Detection. For all other commands the Target shall ensure that the first modulation edge within the start bit is 
aligned to the bit-grid according to the definition of table 6. 

1 1 .2.1 .3 Frame Response time Target to Initiator 

This is the time between the last modulation transmitted by the Target and the first pause transmitted by the Initiator 
and shall be at least 1 172/fc. 



11.2.1.4 



Sense Guard Time 



The Sense Guard Time is defined as the minimum time between the start bits of two consecutive SENS_REQ 
commands. It has the value 7 000/fc. 

11.2.1.5 Frame formats 

The following frame types shall be defined as: 

• Short Frames for commands defined in 11.2.1.5.1. 

• Standard Frames for regular commands in 11 .2. 1 .5.2. 

• Bit oriented Single Device Detection frame for SDD_REQ command in 1 1 .2. 1 .5.3. 

11.2.1.5.1 Short frame 

A short frame shall be used to initiate communication and consist of, in the following order: 

• Start of communication. 

• 7 data bits transmitted Isb first (for command coding see 1 1.2.1.16). 

• End of communication. 
No parity bit is added. 





bitO 


1 biti 


1 bit 2 


1 bit 3 1 


bit 4 


1 bits 


1 bite 




Start 


Command 


End 



Figure 8: Short frame 

11.2.1.5.2 Standard frame 

Standard frames shall be used for data exchange and consist of, in the following order: 

• Start of communication. 

• n X (8 data bits + odd parity bit). With n > 1 . The Isb of each byte shall be transmitted first. See 11.2.1.16. 
Each byte shall be followed by an odd parity bit. The parity bit P shall be set such that the number of ONEs is 
odd in (bit to bit 7, P). 
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• End of communication. 





ByteO 




Bytel 






Byten 






Start 


bit 1 bit 1 1 .. 1 bit 6 1 bit 7 


P 


bit 1 bit 1 1 .. 1 bit 6 1 bit 7 


P 




bitO 1 .. |bit7 


P 


End 




Command or Data 




Data 






Data 







11.2.1.5.3 



Figure 9: Standard Frame 



Bit oriented Single Device Detection frame 



A collision shall be detected when at least two Targets transmit different bit patterns to the Initiator. In this case the 
carrier frequency shall be modulated with the subcarrier for the whole bit duration for at least one bit. 

Bit oriented SDD frames shall only be used during bit frame SDD and shall in fact for standard frames with a length of 
7 bytes, split into two parts: 

• Part 1 for transmission from Initiator to Target. 

• Part 2 for transmission from Target to Initiator. 

For the length of part 1 and part 2, the following rules shall apply: 

• Rule 1 : The sum of data bits shall be 56. 

• Rule 2: The minimum length of part 1 shall be 16 data bits. 

• Rule 3: The maximum length of part 1 shall be 55 data bits. 

Consequently, the minimum length of part 2 shall be 1 data bit and the maximum length shall be 40 data bits. 
Since the split can occur at any bit position within a byte, two cases are defined: 

• Case FULL BYTE: Split after a complete byte. A parity bit shall be added after the last data bit of Part 1 . 

• Case SPLIT BYTE: Spht within a byte. No parity bit shall be added after the last data bit of Part 1 . The first 
parity bit from Part 2 is undefined. 

The following examples for case FULL BYTE and case SPLIT BYTE define the bit organization and order of bit 
transmission. 

These examples include proper values for SEL_PAR and BCC. 

Standard Frame, split after 3rd complete data byte 





ByteO 


P 


Bytel 


P 


Byte 2 


P 


Byte 3 


P 


Byte 4 


P 


Byte 5 


P 


Bytes 


P 




Start 


SEL CMD 
(93) 


1 


SEL PAR 

(40) 





NfcidIO 
(35) 


1 


nfcidi 1 
(20) 





nfcidi 2 
(EF) 





Nfcidi 3 
(AD) 





BCC 

(75) 





End 



Single Device Detection, Part 1 : Initiator to Target 



Initiator to Target 




ByteO 


P 


Bytel 


P 


Byte 2 


P 




Start 


SEL CMD 
(93) 


1 


SEL PAR 

(40) 





nfcidIO 
(35) 


1 


End 



Single Device Detection, Part 2: Target to Initiator 



Target to Initiator 




Byte 3 


P 


Byte 4 


P 


Byte 5 


P 


Byte 6 


P 




Start 


nfcidi 1 
(20) 





Nfcidi 2 

(EF) 





nfcidi 3 
(AD) 





BCC 

(75) 





End 



Figure 10: Bit organization and transmission of 
bit oriented single device detection frame, case FULL BYTE 
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Standard Frame, split after 3rd complete byte + 4 data bits 





ByteO 


P 


Bytel 


P 


Byte 2 


P 


Byte 3 
bits 0-7 


P 


Byte 4 


P 


Byte 5 


P 


Byte 6 


P 




Start 


SEL CMD 

(93) 


1 


SEL PAR 

(40) 





nfcidIO 
(35) 


1 


00000100 
(20) 





nfcid12 
(EF) 
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(AD) 





BCC 

(75) 





End 



Single Device Detection, Part 1 : Initiator to Target 



Initiator to Target 




ByteO 


P 


Bytel 


P 


Byte 2 


P 


bits 0-3 




Start 


SEL CMD 
(93) 


1 


SEL PAR 

(40) 





nfcidIO 
(35) 


1 


0000 


End 



Single Device Detection, Part 2: Target to Initiator 





bits 4-7 1 P 


Byte 4 


P 


Bytes 


P 


Byte 6 


P 




Start 


0100 


X 


nfcid12 
(EF) 





nfcid13 
(AD) 





BCC 

(75) 





End 



Figure 11 : Bit organization and transmission of 
bit oriented single device detection frame, case SPLIT 

For a SPLIT BYTE, the first parity bit of part 2 shall be ignored by the Initiator. 

11.2.1.6 CRC fori 06 kbps 

The CRC for the Passive communication mode at 106 kbps is defined in A. 1. 

11.2.1.7 Target States 

The following clauses provide descriptions of the States for a Target specific to the bit collision detection protocol. 
Targets shall react to valid received frames only. No response shall be sent when transmission errors are detected. 

11.2.1.8 POWER-OFF State 

In the POWER-OFF State, the Target shall not be powered by the RF field of the initiator due to a lack energy. 
If the Target is in an energizing magnetic field greater than H^^^ it shall enter its SENSE State. 

11.2.1.9 SENSE State 

In the SENSE State, the Target is powered. It listens for commands and shall recognize SENS_REQ or ALL_REQ 
Commands. 

The Target enters the RESOLUTION State when it has received a valid SENS_REQ or ALL_REQ Command and 
transmitted its SENS_RES. 

If the Target receives in SENSE State any other valid or invalid command it shall stay in SENSE State. 

11.2.1.10 RESOLUTION State 

In the RESOLUTION State, the bit frame single device detection method may be applied. Cascade levels are handled 
inside this State to get the complete NFCIDL See U.2.L26. 

The Target enters the SELECTED State when it has received a valid SEL_REQ with its complete NFCIDl and sends 
the SEL_RES back to the initiator. 
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If the Target receives in the RESOLUTION State any other valid or invalid command it shall fall back to the SENSE 
State. 

11.2.1.11 SELECTED State 

In the SELECTED State, the Target shall listen depending on the coding in the SEL_RES to an ATR_REQ command or 
a valid proprietary command. 

The Target shall enter the SLEEP State when a valid SLP_REQ Command is received. In the transport protocol the 
DSL commands are specified to return the Target to its SLEEP State. 

If the Target receives in the SELECTED State any other valid or invalid command it shall fall back to the SENSE State. 

11.2.1.12 SLEEP State 

In the SLEEP State, the Target shall respond only to an ALL_REQ Command that transits the Target to its 
RESOLUTION* State. 

The Target shall enter the RESOLUTION* State after it has received a valid ALL_REQ Command and transmitted its 
SENS_RES. 

If the Target receives in SLEEP State any other valid or invalid command it shall stay in SLEEP State. 

11.2.1.13 RESOLUTION* State 

The RESOLUTION* State shall be similar to the RESOLUTION State, a bit frame SDD method can be applied. 
Cascade levels shall be handled inside this State to get all NFCIDl CLn. 

The Target enters the SELECTED* State when it is selected with its complete NFCIDl. 

If the Target receives in the RESOLUTION* State any other valid or invalid command it shall fall back to the SLEEP 
State. 

11.2.1.14 SELECTED* State 

The SELECTED* State shall be similar to the SELECTED State; the Target shall listen depending on the coding in the 
SEL_RES to an ATR_REQ command or a valid proprietary command. The Target shall enter the SLEEP State when a 
valid SLP_REQ Command is received. 

In the transport protocol the DSL command are specified to return the Target to its SLEEP State. 

If the Target receives in the SELECTED* State any other valid or invalid command it shall fall back to the SLEEP 
State. 

11.2.1.15 Command Set 

The commands used by the Initiator and the responses by the Targets are described in table 7. 

Table 7: Command Set 



Mnemonic 


Definition 


SENS REQ 


Sense Request (sent by Initiator) 


SENS RES 


Sense Response (sent by Target) 


ALL REQ 


Wal<eup ALL Request (sent by the Initiator) 


SDD REQ 


Single device detection Request (sent by Initiator) 


SEL REQ 


Select Request (sent by Initiator) 


SEL RES 


Select Response (sent by Target) 


SLP REQ 


Sleep Request (sent by Initiator) 



£75/ 



27 



ETSI TS 102 190 VI. 1.1 (2003-03) 



1 1 .2.1 .1 6 SENS_REQ and ALL_REQ Command 

The SENS_REQ and ALL_REQ Commands shall be sent by the Initiator to probe the field for Targets. They shall be 
transmitted within a Short Frame. 

Particularly the ALL_REQ Command shall be sent by the Initiator to put Targets which have entered the SLEEP State 
back into the RESOLUTION* State. They shall then participate in further SDD procedures. Table 8 shows the coding 
of SENS_REQ and ALL_REQ Commands, which use the Short frame format. 

Table 8: Coding of SENS_REQ and ALL_REQ 



Short Frame Commands 


b6 


b5 


b4 


b3 


b2 


b1 


bO 


SENS REQ 





1 








1 


1 





ALL REQ 


1 





1 








1 





Proprietary 


1 








X 


X 


X 


X 


Proprietary 


1 


1 


1 


1 


X 


X 


X 


RFU 


All other values 



11.2.1.17 SENS_RES 

After an SENS_REQ command is transmitted by the Initiator, all Targets in the SENSE State shall respond 
synchronously with SENS_RES. 

After an ALL_REQ command is transmitted by the Initiator, all Targets in the SENSE or SLEEP State shall respond 
synchronously with SENS_RES. 

The Initiator shall detect any collision that may occur when multiple Targets respond. 

11.2.1.18 Coding of SENS_RES 

Coding for bit frame single device detection is specified as follows: 

Table 9: Coding of SENS_RES 



bit 15 


bit 14 


bit 13 


bit 12 


bit 11 bit 10 bit 9 bits 


bit 7 bit 6 


bits 


bit 4 bit 3 bit 2 bit 1 bit 


ZERO 


ZERO 


ZERO 


ZERO 


Proprietary coding 


NFCID1 size 
bit frame 


ZERO 


Bit frame single device detection 



bits b 15 to b 12 shall be set to ZERO. 

bit bl 1 to b8 indicate additional and proprietary coding and shall be ignored on interchange. 

bits b7 and b6 code the NFCIDl size (single, double or triple). See table 10. 

Table 10: Coding of bit 7, bit 6 for bit frame single device detection 



bit 7 


bite 


Explanation 








NFCID1 size: single 





1 


NFCID1 size: double 


1 





NFCID1 size: triple 


1 


1 


RFU 



bit 5 shall be set to ZERO. 

One out of the five bits bO, bl, b2, b3 or b4 shall be set to ONE to indicate bit frame SDD. 
See table 11. 
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Table 1 1 : Coding of bO to b4 for bit frame SDD 



b4 


b3 


b2 


b1 


bO 


Meaning 


1 














bit frame SDD 





1 











bit frame SDD 








1 








bit frame SDD 











1 





bit frame SDD 














1 


bit frame SDD 



1 1 .2.1 .1 9 SDD_REQ and SEL_REQ Command 

These commands shall be used during an SDD. The SDD_REQ and SEL_REQ Commands consist of: 

• SEL_CMD (1 byte code; see table 12). 

• SEL_PAR (1 byte code; see tables 13 and 14). 

• to 40 data bits of NFCIDl CLn according to the value of SEL_PAR. 
SEL_CMD specifies the cascade level CLn. 

The SDD_REQ command shall be transmitted within the bit oriented SDD Frame. 

The SEL_REQ command shall be transmitted within the Standard Frame. 

As long as SEL_PAR does not specify 40 valid bits, the command shall be called SDD_REQ Command, where the 
Target remains in RESOLUTION or RESOLUTION* State. 

If SEL_PAR specifies 40 data bits of NFCIDl CLn (SEL_PAR = (70)), a CRC shall be appended. This command shall 
be called SEL_REQ command. 

If the Target has transmitted the complete NFCIDl, it transits from RESOLUTION State to SELECTED State or from 
RESOLUTION* State to SELECTED* State and indicates in its SEL_RES response that NFCIDl is complete. 

Otherwise, the Target remains in RESOLUTION or RESOLUTION* State and the Initiator shall initiate a new SDD 
with increased cascade level. 

11.2.1.20 Coding of SEL_CMD 

Table 12 defines the coding of the SEL_CMD byte. 

Table 12: Coding of SEL_CI\flD 



bit? 


bite 


bits 


bit 4 


bit 3 


bit 2 


biti 


bitO 


Hex 
notation 


Meaning 


1 








1 








1 


1 


(93) 


Select cascade level 1 


1 








1 





1 





1 


(95) 


Select cascade level 2 


1 








1 





1 


1 


1 


(97) 


Select cascade level 3 


Other settings are RFU 





11.2.1.21 Coding of SEL_PAR 

The length of the SEL_PAR shall be 1 byte. The upper 4 bits shall be called "Byte count" and shall specify the integer 
part of the number of all valid data bits transmitted by the Initiator (including SEL_CMD and SEL_PAR) divided by 8. 
Consequently, the minimum value of "Byte count" shall be 2 and the maximum value shall be 7. 
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Table 13: Coding of SEL_PAR upper 4 bits 



bit? 


bite 


bits 


bit 4 


Meaning 








1 





Byte count = 2 








1 


1 


Byte count = 3 





1 








Byte count = 4 





1 





1 


Byte count = 5 





1 


1 





Byte count = 6 





1 


1 


1 


Byte count = 7 



The lower 4 bits shall be called "bit count" and specify the number of all valid data bits transmitted by the Initiator 
(including SEL_CMD and SEL_PAR) modulo 8. 

Table 14: Coding of SEL_PAR, lower 4 bits 



bit 3 


bit 2 


biti 


bitO 


IVIeaning 














bit count = 











1 


bit count = 1 








1 





bit count = 2 








1 


1 


bit count = 3 





1 








bit count = 4 





1 





1 


bit count = 5 





1 


1 





bit count = 6 





1 


1 


1 


bit count = 7 



11.2.1.22 Coding of SEL_RES 

The SEL_RES shall be transmitted by the Target when SEL_PAR has specified 40 valid data bits and when all these 
data bits match with NFCIDl CL«. The SEL_RES byte shall be followed by 2 bytes CRC according to A.l. 



ByteO 


Byte 1 1 Byte 2 


SEL RES 


CRC 



Figure 12: Select Response (SEL_RES) 

The coding of bit 2 (cascade bit) and b6 is given in table 15. 

The coding of bit 6 in SEL shall indicate the NFCIP- 1 Target device Attribute Request ability. 

Table 15: Coding of SEL_RES 



bit? 


bite 


bits 


bit 4 


bit 3 


bit 2 


biti 


bitO 


IVIeaning 


X 


X 


X 


X 


X 


1 


X 


X 


Cascade bit set: NFCID1 not complete. 


X 


1 


X 


X 


X 





X 


X 


NFCID1 complete, Target compliant with NFC 
transport protocol. Request for Attributes supported. 


X 





X 


X 


X 





X 


X 


NFCID1 complete, Target not compliant with 
transport protocol. Request for Attributes not 
supported. 



11 .2. 1 .23 Select sequence 



The purpose of the select sequence is to get the NFCIDl from one Target and to select this Target for further 
communication. 
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1 1 .2. 1 .24 Select sequence flowchart 



NFCIP-1 



Start 



Send SENS_REQ 



Receive SENS RES 




Single Device Detection 



Select 
cascade level 1 



^A 



Increase 
cascade level 



Perform 
SDD 



NFCIDl 

not complete 




NFCIDl 

I complete 



ATR_REQ 



NFCIDl complete, 
target not compliant 
to the transport 
protocol 



Proprietary 
commands 
and protocols 



Figure 13: Initialization and SDD Flow Chart for Initiator 

1 1 .2.1 .25 SDD loop within each cascade level 

The following algorithm shall apply to the SDD loop; If the NFCID 1 of a Target is complete, the Initiator may skip 
from step 2 to step 10 selecting this Target without performing the SDD loop. 

This clause describes the bit collision detection protocol applicable for NFCIP-1 device communication at 106 kbps in 
the Passive communication mode. 
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The following steps define SDD Flow: 

1) The Initiator shall assign SEL_CMD with the code for the selected SDD type and cascade level. 

2) The Initiator assigns SEL_PAR with the value of (20). This value shall define that the Initiator will transmit no 
part of NFCIDl CLn. Consequently these command forces all Targets in the field to respond with their 
complete NFCIDl CLn. 

3) The Initiator shall transmit SEL_CMD and SEL_PAR. 

4) All Targets in the field shall respond with their complete NFCIDl CLn. 

5) Assuming the Targets in the field have a different NFCIDl, then if more than one-Target responds, a collision 
occurs. If no collision occurs, steps 6 to 10 are skipped. 

6) The Initiator shall recognize the position of the first collision. 

7) The Initiator assigns SEL_PAR with a value that specifies the number of valid bits of NFCIDl CLn. The vaUd 
bits shall be part of the NFCIDl CLn that was received before a collision occurred followed by a ZERO or 
ONE, decided by the Initiator. A typical implementation adds a ONE. 

8) The Initiator shall transmit SEL_CMD and SEL_PAR, followed by the valid bits itself. 

9) Only Targets of which the part of NFCIDl CLn is equal to the valid bits transmitted by the Initiator shall 
transmit their remaining bits of the NFCIDl CLn. 

10) If further collisions occur, steps 6 to 9 shall be repeated. The maximum number of loops will be 32. 

11) If no further collision occurs, the Initiator assigns SEL_PAR with the value of (70).This value shall define that 
the Initiator will transmit the complete NFCIDl CLn. 

12) The Initiator transmits SEL_CMD and SEL_PAR, followed by all 40 bits of NFCIDl CLn, followed by CRC 
as described in A. 1 . 

13) The Target which NFCIDl CLn shall match the 40 bits responds with its SEL_RES. 

14) If the NFCIDl is complete, the Target shall transmit SEL_RES with cleared cascade bit and transit from 
RESOLUTION State to SELECTED State or from RESOLUTION* State to SELECTED* State. 

15) The Initiator shall check if the cascade bit of SEL_RES is set to decide whether further SDD loop with 
increased cascade level shall follow. 

11.2.1.26 NFCIDl contents and cascade levels 

The NFCIDl shall consist of 4, 7 or 10 NFCIDl bytes. Consequently, the Target shall handle up to 3 cascade levels to 
get all NFCIDl bytes. Within each cascade level, a part of NFCIDl shall be transmitted to the Initiator. According to 
the cascade level, three types of NFCIDl size are defined. This NFCIDl size has to be consistent with table 16. 

Table 16: Size Of NFCID1 



NFCIDl size 


Cascade level 


Number of NFCIDl bytes 


single 


1 


4 


double 


2 


7 


triple 


3 


10 



The NFCIDl shall be a random number that is dynamically generated by the Target. The first byte (nfcidlO) of the 
NFCIDl shall assign the content of the following bytes of the NFCIDl. See table 17. 
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Table 17: Single size NFCIDIs 



nfcidIO 


Description 


(08) 


nfcidi 1 to nfcidi 3 is a random number which shall be dynamically generated 


(xO) to (x7) 


proprietary fixed number 


(x9) to (xE) 


(18)to(F8) 


Set to all ZEROS. 


(xF) 



The value (88) of the cascade tag CT shall not be used for nfcidIO in single size NFCIDI. 

The first byte of the NFCIDI describes the CT in case of double size NFCIDI, in case of triple size NFCIDI the CT 
byte describes the first and the 5th byte of the NFCIDI. The cascade tag CT shall be set to (88) in case of double and 
triple size NFCIDI. 

Table 18: Double and triple size NFCIDIs 



nfcidIO 


Description 


(01)-(7E) 


Proprietary 


All other values 


RFU 



In case of double or triple NFCIDIs the nfcidIO to nfcidl6 or nfcidIO to nfcidl9 shall be a random number that is 
dynamically generated by the Target. 

Single size NFCIDI 



Initiatorl (93) 1 


Target | nfcidIO | nfcid11 | nfcidi 2 | nfcid13 | 


BCC 


Cascade Level 1 
1 1 



Double size NFCIDI 



Initiator 



(93) 



Target 



CT nfcid 1 nfcid 1 1 nf cid 1 2 BCC 



(95) 








CT 


1 nfcid 1 3 1 nfcid 1 4 | nfcid 1 5 1 BCC 



Cascade Level 1 



Cascade Level 2 



Triple Size NFCIDI 



Initiator 


(93) 


(95) 




(97) 




Target 


CT|nfcid10|nfcid11|nfcid12|BCC 




CT|nfcid13|nfcid14|nfcid15|BCC 




|nfcid16|nfcid17|nfcid18|nfcid19|BCC 


Cascade Level 1 

1 1 




Cascade Level 2 

1 


Cascade Level 3 

1 



Figure 14: Usage of cascade levels 

The purpose of the cascade tag shall be to force a collision with Targets that have a smaller NFCIDI size. The 
following algorithm shall apply to the Initiator to get the complete NFCIDI: 

• The Initiator shall select cascade level 1 . 

• The SDD shall be performed. 

• The Initiator shall check the cascade bit of SEL_RES. 

• If the cascade bit is set, the Initiator shall increase the cascade level and initiate a new single device detection. 
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11.2.1.27 SLP_REQ Command 

The SLP_REQ Command consists of two bytes followed by CRC and shall be transmitted within Standard Frame. The 
CRC is described in A.l. 



ByteO 


Bytel 


Byte 2 | Byte 3 


(50) 


(00) 


CRC 



Figure 15: SLP_REQ Command 

If the Target responds with any modulation during a period of 1 ms after the end of the frame containing the SLP_REQ 
command, this response shall be interpreted as "not acknowledge". 

1 1 .2.2 Initialization and SDD at 21 2 kbps and 424 kbps 



11.2.2.1 



Start and end of communication 



The start of the Passive communication shall be signalled by the presence of modulation of the carrier frequency. The 
communication shall start with the preamble sequence of minimum 48 bits with all logical "ZERO" encoded. The end 
of communication shall be forecasted from the Length field of the frame. 



No modulation 



Preamble 



Data packet 



No modulation 



Figure 16: Start and end of communication 

After one NFCIP-1 device has finished communication, the other shall delay for a period of at least 8 x 64/fc before 
starting transmission by sending the preamble sequence as shown in figure 17. 



Data packet 



Delay 



Preamble 



Data packet 



Figure 17: Delay between frames 



1 1 .2.2.2 Frame format 

The frame format of shall consist of Preamble, SYNC, Length, Payload, and CRC. 

The Preamble shall be 48 bits minimum all logical ZEROs. 

The SYNC shall be 2 bytes. The 1st byte of the SYNC shall be (B2) and the 2nd byte shall be (4D). 



Preamble SYNC Length Payload CRC 



Figure 18: Frame format 

The Length shall be an 8-bit field and it shall be set to the number of bytes to be transmitted in Payload plus 1 . The 
range of the Length shall be 2 to 255, and other settings are RFU. 

The Payload shall consist of n 8-bit-bytes of data where n is indicated by the number of data bytes. 
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The CRC shall be calculated according to A. 3. 

1 1 .2.2.3 Single Device Detection at 202 kbps and 424 kbps 

The basic technique of the SDD procedure shall be the Time Slot method. The number of the Slot shall be the integer 
value beyond zero. The Initiator shall send Polling Requests. The Target shall respond at random in each controllable 
Time Slot. The Initiator shall be able to read NFCID2 data (see 1 1 .2.2.4) of Target(s) in different Time Slots. 

After obtaining NFCID2 data from Target(s) in the operating field, the Initiator may communicate with multiple 

Targets. 

Up to 16 Time Slots may be supported by agreement between the interchange parties. The number of Time Slot may be 
indicated by the value TSN in the Polling Request Frame from the Initiator. 

A Target, which is already powered up, responds to the Initiator according to the following rules after receiving the 
Polling Request Frame from the Initiator. 

1) The Target shall generate a random number R in the range to TSN - 1 . 

2) The Target shall wait until the Time Slot is matched to R, then send the Polling Response Frame and wait for 
the next Request. The Target may ignore a Polling Request to reduce instances of collision of Responses. 

The communication between the Initiator and the Target shall be initiated as follows: 

1) The Target gets power from the operating field generated by the Initiator. 

2) The Target shall become ready for receiving a Polling Request from the Initiator in maximum 2 seconds from 
power up. 

3) The Target shall wait for a Polling Request sent from the Initiator. The Initiator may send a Polling Request 
without waiting for the Target to become ready. 

4) If the Initiator fails to receive Polling Response, then the Initiator may send Polling Request again. The 
Initiator of the Passive communication mode shall keep RF power on while executing the SDD procedure. 

The delay Td between the end of the Request Frame and the first Time Slot shall be 5 12 x 64/fc. 

The Time Slot unit Ts shall be 256 x 64/fc. 

Figure 19 illustrates an example situation of the SDD by Time Slot. In this example, 5 Targets are responding. The 
Initiator may be able to get the Response information of the Target 2, 4, and 5 excluding 1 and 3. Because a collision 
has occurred at the Time Slot 1. 



The Initiator may repeat SDD procedure. 
Jd 



<-Ts^ 



<-Ts^ 



<-Ts^ 



<-Ts^ 



Time^ 



REQ from 
Initiator 



Time Slot 



RES from 
Target 4 



Time Slot 1 



RES from 
Target 1 



RES from 
Target 3 



Time Slot 2 



RES from 
Target 5 



Time Slot 3 



RES from 
Target 2 



Figure 19: Single Device Detection by Time Slot 
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11.2.2.4 



NFCID2 contents 



NFCID2 shall be an 8-byte number for identifying NFCIP-1 devices. The 2-byte prefix code shall be followed by a 
6-byte number in the NFCID2. The prefix code shall define the characteristics for the 6-byte number. 

The 6-byte number shall be randomly generated while the prefix code is (01) (FE). Other settings for the prefix code are 
RFU. 

1 1 .2.2.5 Polling Request Frame format 

An Initiator for finding Targets shall send polling frame. 



Preamble 
(48 bit min.) 


SYNC 
(16 bit) 


Length 
(8 bit) 


Payload 


CRC 

(16 bit) 


(00) 


1 (FF) 


1 (FF) 1 


(00) 


1 TSN 



Figure 20: Polling Request Frame format 

The Preamble shall be 48 bits minimum all logical ZEROs. 

The synchronization (SYNC) pattern shall be 2 byte. The 1st byte of the synchronization pattern shall be (B2) and the 
2nd byte shall be (4D). 

The Length shall be set to (06). 

The 1st byte of the Payload shall be set to (00). 

The 2nd byte and the 3rd of Payload shall be set to (FF) and other settings are RFU. 

The 4th byte of Payload shall be set to (00), and other settings are RFU. 

The Time Slot Number (TSN) indicates the number of Time Slots plus 1 . The TSN shall be (00), (01), (03), (07), or 
(OF). Any other settings are RFU. 

The CRC shall be calculated according to A. 3. 

Figure 19 illustrates an example where the TSN is (03). If the TSN is set to (00) then only the Time Slot shall be used. 

1 1 .2.2.6 Polling Response Frame format 

Target shall send the following frame as the Polling Response toward the Polling Request. 



Preamble 
(48 bit min.) 


SYNC 
(16 bit) 


Length 
(8 bit) 


Payload 


CRC 

(16 bit) 


(01) 


NFCID2 1 


Pad 



Figure 21 : Polling Response Frame format 

The Preamble shall be 48 bits minimum all logical "ZERO". 

The synchronization (SYNC) pattern shall be 2 byte. The 1st byte of the synchronization pattern shall be (B2) and the 
2nd byte shall be (4D). 

The Length field shall be set (12). 

The start byte of the Payload shall be set to (01). The Payload shall contain 8-byte of NFCID2 and 8-byte of Pad. The 
Pad shall be ignored for data interchange. 

The CRC shall be calculated according to A. 3. 
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1 1 .3 Active communication mode 

11.3.1 Initialization at 1 06 kbps, 21 2 kbps and 424 kbps 

The application switches to Initiator for the Active communication mode and may choose 106 kbps, 212 kbps or 
424 kbps. 

1 1 .3.2 Active communication mode RF Collision Avoidance 

The RF Collision Avoidance shall be executed according to the following timing chart. See figure 22. 

The Initiator shall perform the initial RF Collision Avoidance. 

The first command sends by the Initiator is the ATR_REQ in the Active communication mode at a selected 
transfer speed. 

The initiator shall switch off the RF field. 

The Target performs the response RF Collision Avoidance. 

The Target sends the ATR_RES as a response to the ATR_REQ in the same transfer speed as it has received 
the ATR_REQ and switch of the RF field. 

The initiator performs the response RF Collision Avoidance with Time Jitters indicator n = 0. 

The Initiator sends the PSL_REQ in order to change parameter or sends the DEP_REQ to start the data 
exchange protocol. 



RFon 



Request RF off 



RFon 



RF off 



Initiator 



TiDT 

1. Initial 
RF collision 
avoidance 



7\ 7^ 

Trfg 

2. 



Sends Request 
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TarfO 

7. 
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RFon 
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3.DetectsRF field, 
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Tadt 

4. Response 
RF collision 
avoidance 



Tarfg 



Sends Response 



Receive command 



Figure 22: Initialization flow for Active communication mode 

1 1 .3.2.1 Collision Avoidance for Active communication mode 

In case where 2 Targets or more are in the field the one with the lowest n will answer first and the other will not answer. 

In case of 2 or more Targets answering in exactly the same Time Period, the Initiator will detect a collision and it will 
re-send the ATR_R£Q, which is described in 12.5.1.1. 

After the first Target response is detected by the Initiator the Time Jitters parameter indicator n shall be set to for 
further communication. 
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1 2 Transport Protocol 



The transport protocol shall be handled in three parts: 

• activation of the protocol, which includes the Request for Attributes and the Parameter Selection; 

• the data exchange protocol; and 

• the deactivation of the protocol including the Deselect and the Release. 



12.1 Transport Data 



User data shall be transported by the Transport Data field in the Frame format. Figure 23 shows the position of the 
Transport Data field in each Frame format. 

The structure for the Frame format for 106 kbps is shown in clause 11.2.1.5.2. The start byte SB shall be set to (FO). 
The LEN byte shall be set to the length of the Transport Data field plus 1 . The range of the LEN shall be in the range of 
3 to 255. The El is the CRC for the Frame format of 106 kbps as described in A.l. Other settings of LEN are prohibited 
by the present document. 

The structure for the Frame format for 212 kbps and 424 kbps as shown in the clause 1 1.2.2.2 describing the Preamble 
PA and the Synchronous pattern bytes SYNC. 

The LEN byte shall be set to the length of the Transport Data field plus 1 . The value of LEN shall be in the range of 3 to 
255. The E2 is the CRC for the Frame format of 212 kbps and 424 kbps as described in A. 3. Other settings of LEN are 
prohibited by the present document. 

The Transport data field contains the mandatory command bytes CMDO and CMDl as described in clause 12.4 and the 
data bytes Byte to Byte n. The content of Byte to Byte n depends on the command byte CMDl and may contain 
information. In that case they are mandatory. Data bytes are optional. 



Frame Format 
for 1 06 kbps 



Frame Format 
for 212 kbps 
and 424 kbps 
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Figure 23: Transport Frame format Definition 



12.2 Passive communication mode Activation flow 

The following activation sequence shall be applied: 

1) The Initiator shall perform the initial RF Collision Avoidance sequence as defined in clause 11.1.1. 

2) The Initiator shall perform the Initialization and SDD for the Passive communication mode at a chosen transfer 
speed as defined in clause 1 1.2. 

3) The support of the NFCIP-1 protocol shall be checked at the different transfer speeds according to the 
Attribute Request as described in clause 12.5.1.1. 

4) The Target may fall back to the Initialization and SDD if no ATR_REQ is supported. 

5) The ATR_REQ may be send by the Initiator as a next command after receiving the Attribute Request is 
available. 

6) The Target shall send its ATR_RES as answer to the ATR_REQ. The Target shall only answer to the 
ATR_REQ if the ATR_REQ is received directly after selection. 
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7) If the Target supports any changeable parameter in the ATR_REQ, a PSL_REQ may be used by the Initiator 
as the next command after receiving the ATR_REQ to change parameters. 

8) The Target shall send a PSL_RES as answer to the PSL_REQ. 

9) A Target does not need to complement the parameter selection, if it does not support any changeable 
parameters in the ATR_RES. 

10) The transparent data shall be sent using the data exchange transport protocol. 

The Initiator activation sequence for a Target in the Passive communication mode is shown in figure 24. 
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Figure 24: Activation protocol in Passive communication mode 
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12.3 Active communication mode Activation flow 

The following activation sequence for the protocol in the Active communication mode shall be applied: 

1) The Initiator shall perform the initial RF Collision Avoidance sequence as defined in clause 11.1.1. 

2) The Initiator shall switch to the Active communication mode and select the transfer speed. 

3) The Initiator shall send the ATR_REQ. 

4) The Target shall send its ATR_RES in response to the ATR_REQ. After a successful response the device is 
selected. 

5) If the Initiator detects a collision of data the ATR_REQ shall be re-sent. 

6) It the Target supports any changeable parameter in the ATR_RES, a PSL_REQ may be used by the Initiator as 
the next command after receiving the ATR_RES to change parameters. 

7) The Target shall send a PSL_RES in response to the PSL_REQ. 

8) A Target does not need to complement the parameter selection, if it does not support any changeable 
parameters in the ATR_RES . 

The Initiator activation sequence for a Target in the Active communication mode is shown in figure 25. 
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Figure 25: Activation Protocol in Active communication mode 
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12.4 Commands 

The Command Bytes shall consist of 2 bytes. The first byte shall be CMDO and the second byte shall be CMDl. The 
code of the Command Bytes shall specify the Request and Response according to the table 19. 

Table 19: NFCIP-1 Protocol Command Set 



Mnemonic 


Command Bytes 


Definition 




CMDO 


CMDl 




AIR REQ 


(D4) 


(00) 


Attribute Request (sent by Initiator) 


AIR RES 


(D5) 


(01) 


Attribute Response (sent by Target) 


WUP REQ 


(D4) 


(02) 


Wal<eup Request (sent by Initiator in Active mode only) 


WUP RES 


(D5) 


(03) 


Wakeup Response (sent by Target in Active mode only) 


PSL REQ 


(D4) 


(04) 


Parameter selection Request (sent by Initiator) 


PSL RES 


(D5) 


(05) 


Parameter selection Response (sent by Target) 


DEP REQ 


(D4) 


(06) 


Data Exchange Protocol Request (sent by Initiator) 


DEP RES 


(D5) 


(07) 


Data Exchange Protocol Response (sent by Target) 


DSL REQ 


(D4) 


(08) 


Deselect Request (sent by Initiator) 


DSL RES 


(D5) 


(09) 


Deselect Response (sent by Target) 


RLS REQ 


(D4) 


(OA) 


Release Request (sent by Initiator) 


RLS RES 


(D5) 


(OB) 


Release Response (sent by Target) 



1 2.5 Activation of the protocol 

12.5.1 Attribute Request and Response Commands 

12.5.1 .1 Attribute Request (ATR_REQ) 

This clause defines the Attribute Request ATR_REQ with all its parameter bytes. The Initiator shall send the 
ATR_REQ to the selected Target. 



CMDO 


CMDl 


ByteO 


... 


Byte 9 


Byte 10 


Byte 11 


Byte 12 


Byte 13 


Byte 14 


... 


Byten 


(D4) 


(00) 


nfcidSiO 




nfcid3i9 


DIDi 


BSi 


BRi 


PPi 


[Gi[0]] 




mn]] 



Figure 26: Structure of the ATR_REQ 

12.5.1.1.1 Definition of the ATR_REQ bytes 

CMD 0: Shall be set to (D4). 
CMD 1: ATR_REQ 

The ATR_REQ byte shall specify the Attributes Request for the Target. The value of ATR_REQ shall be set to (00). 

Byte to Byte 9: NFCID3i 

The 10 nfcid3i bytes define the random identifier NCID3i of the Initiator. NFCID3 shall be an ID dynamically 
generated by the application. 

Byte 10: DIDi 

The DID byte shall be used for multiple data exchange protocol activation with more than one Target. The range of the 
DIDi shall be defined between 1 and 14. The value ZERO shall be used, if no DIDi is used during the data transport 
protocol. All other values are prohibited by the present document. 
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Byte 11: BSi 

The BSi byte shall specify the send-bit rates supported by the Initiator device. The coding of bits is as follows: 
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Figure 27: Coding of the BSi byte 

bit 7 to bit 4: shall be set to ZERO, all other values are RFU. 

bit 3: DSi = 64 supported, if bit is set to ONE. 

bit 2: DSi = 32 supported, if bit is set to ONE. 

bit 1: DSi = 16 supported, if bit is set to ONE. 

bit 0: DSi = 8 supported, if bit is set to ONE. 
Byte 12: BRi 
The BRi byte shall specify the receive-bit rates supported by the Initiator device. The coding of bits is as follows: 
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Figure 28: Coding of the BRi byte 

bit 7 to bit 4: shall be set to ZERO, all other values are RFU. 

bit 3: DRi = 64 supported, if bit is set to ONE. 

bit 2: DRi = 32 supported, if bit is set to ONE. 

bit 1: DRi = 16 supported, if bit is set to ONE. 

bit 0: DRi = 8 supported, if bit is set to ONE. 
Bytel3: PPi 
The PPi byte specifies optional parameters used by Initiator device. The coding of bits shall be as follows: 
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Figure 29: Coding of the PPi byte 

bit 7 and bit 6: Shall be set to ZERO. 
bit 5 and bit 4: Length Reduction value. 

Table 20: Definition of LRi 



LRi 


LEN„;,x 


00 


Only Byte to Byte 63 is valid in the Transport Data 


01 


Only Byte to Byte 127 is valid in the Transport Data 


10 


Only Byte to Byte 191 is valid in the Transport Data 


11 


Only Byte to Byte 255 is valid in the Transport Data 



bit 3 and bit 2: Shall be set to ZERO. 

bit 1 : If bit is set to ONE then it indicates General bytes are available. 

bit 0: If bit is set to ONE then it indicates the Initiator uses NAD. See 12.6.1.1.1. 
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Byte 14 to Byte n: Gi[0] to Gi[n] 

The general bytes shall be optional and designate general information. The maximum length of the ATR_REQ 
subtracted by the mandatory bytes give the maximum number of general bytes. 

12.5.1.2 Attribute Response (ATR_RES) 

This clause defines the answer to request for attributes. The ATR_RES shall be the response to the ATR_REQ and shall 
be sent by the selected NFCIP-1 Target device. 
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Figure 30: Structures of the ATR_RES 

12.5.1.2.1 Definition of the ATR_RES bytes 

CMD 0: Shall be set to (D5). 

CMD 1: ATR_RES 

The ATR_RES byte shall specify the Response for the Initiator. The value of ATR_RES shall be set to (01). 

Byte to Byte 9: NFCID3t 

The 10 nfcid3t bytes define the random identifier NCID3t of the Target. NFCID3 should be an ID generated by the 
application. The content of NFCID3 may be the same as NFCIDl or NFCID2. 

Byte 10: DIDt 

The DID byte shall be used for multiple data transport protocol activation with more then one Target. The DIDt shall 
have the same value as the DIDi. All other values are prohibited by the present document. For usage of DIDt 
see 12.5.1.1.1. 

Byte 11: BSt 

The BSt byte shall specify the supported transfer speed of the Target device. The coding of bits is defined as follows: 
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Figure 31 : Coding of the BSt byte 

bit 7 to bit 4: Shall be set to ZERO. 

bit 3: DSt = 64 supported, if bit is set to ONE. 

bit 2: DSt = 32 supported, if bit is set to ONE. 

bit 1: DSt = 16 supported, if bit is set to ONE. 

bit 0: DSt = 8 supported, if bit is set to ONE. 
Byte 12: BRt 
The BRt byte shall specify the supported receive bit rates of the Target device. The coding of bits is defined as follows: 
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Figure 32: Coding of the BRt byte 

bit 7 to bit 4: Shall be set to ZERO. 

bit 3: DRt = 64 supported, if bit is set to ONE. 
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bit 2: DRt = 32 supported, if bit is set to ONE. 

bit 1: DRt = 16 supported, if bit is set to ONE. 

bit 0: DRt = 8 supported, if bit is set to ONE. 

Byte 13: TO 

The TO byte shall specify the timeout value of the Target NFClP-1 device for the transport protocol. The timeout is 
specified as follows: 



bit? 


bite 


bits 


bit 4 


bit 3 


bit 2 


biti 


bitO 


ZERO 


ZERO 


ZERO 


ZERO 


WT 


WT 


WT 


WT 



Figure 33: Coding of the TO byte 

bit 7 to bit 4: Shall be set to all ZEROs. 

bit 3 to bit 0: WT: Waiting Time. 

The Response Waiting Time (RWT) shall be calculated by the following formula: 

RWT = (256 X 16/fc) x 2WT 

Where the value of WT shall be the range from to 14 and the value of 15 is RFU. The default value of WT shall be 4, 
which gives a RWT value of 4,8 ms. 

For WT = 0, RWT = RWT]y[jf^ (302 ^s). 

For WT = 14, RWT = RWT^ax (4 949 ms). 

Byte 14: PPt 

The PPt byte specifies optional parameters used by Target device. The coding of bits shall be as follows: 
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Figure 34: Coding of the PPt byte 

bit 7 and bit 6: Shall be set to ZERO. 
bit 5 and bit 4: Length Reduction value. 

Table 21 : Definition of LRt 



LRt 


LENmax 


00 


Only Byte to Byte 63 is valid in the Transport Data 


01 


Only Byte to Byte 127 is valid in the Transport Data 


10 


Only Byte to Byte 191 is valid in the Transport Data 


11 


Only Byte to Byte 255 is valid in the Transport Data 



bit 3 and bit 2: Shall be set to ZERO. 

bit 1 : If bit is set to ONE then it indicates General bytes available. 

bit 0: If bit is set to ONE then it indicates the Target uses NAD. 

Byte 14 to Byte n: Gt[0] to Gt[n] 

The Gt bytes shall be optional and designate general information. The maximum length of the ATR_RES subtracted by 
the mandatory bytes gives the maximum number of general bytes. 



£75/ 



46 ETSI TS 102 190 VI. 1.1 (2003-03) 

1 2.5.1 .3 Handling of ATR_REQ and ATR_RES 

12.5.1.3.1 Initiator rules 

When the Initiator has sent the ATR_REQ and receives a valid ATR_RES the Initiator shall continue with operation. 

In any other case the Initiator shall retransmit the ATR_ REQ before it shall use the deactivation sequence as defined in 
clause 12.7. In case of failure of the deactivation sequence it may use the SLP_REQ command as defined in 
clause 11.2.1.27 for Passive communication mode at 106 kbps. 

12.5.1.3.2 Target rules 

When the Target has been selected by the last command (for passive mode only); and 

a) Receives a valid ATR_REQ, the Target: 

shall send its ATR_RES; 

shall disable to receive a subsequent ATR_REQ. 

b) Receives any other valid or invalid frame, except a SLP_REQ command for passive communication mode at 
106 kbps, the Target: 

shall ignore the block; and 

shall remain in receive mode. 

12.5.1.4 Handling of timeout TO 

Defined by the initially chosen mode, the communication is either active or passive. The handling of the timeout is 
different for active and passive communication mode. 

12.5.1.4.1 Handling in active mode 

In active mode the communication flow is handled by switching the carrier frequency. 

Initiator: The Initiator shall ignore a Target that exceeded RWT calculated using TO byte in ATR_REQ from a Target 
device and continue operation. 

Target: The Target shall use a TO value that allows common communication and shall use a supervisory pdu 
containing a timeout extension to extend the defined RWT. See 12.6.1.1.1. 

1 2.5.1 .4.2 Handling of timeout in passive mode 

In passive mode the communication is only handled by communication flow. The carrier frequency is not switched. 

Initiator: The Initiator shall first use error handling and if no response is received ignores a Target device that has 
exceeded the specified timeout and continues communication. 

Target: The Target shall use a TO value that allows common communication and shall use a supervisory pdu 
containing a timeout extension to extend the defined RWT. See 12.6.1.1.1. 

12.5.1.5 Handling of DID 

1 2.5.1 .5.1 Handling of DID in active and in passive mode. 

When the Initiator has sent a ATR_REQ containing a DID equal to ZERO; and 
a) received an ATR_ RES containing DID equal to ZERO: 

shall send pdus containing no DID to the Target; and 

shall not activate any other Target while this Target is not deactivated. 
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b) received an ATR_RES containing DID not equal to ZERO: 
shall continue with error handling. 
When the Initiator has sent a ATR_REQ containing a DID not equal to ZERO; and 

a) received an ATR_RES containing the same DID: 

shall send pdus containing the DID to the Target; and 
shall not use the DID for any other Targets; and 
shall not use DID=0 for any other Targets. 

b) received an ATR_RES containing any other DID: 

shall continue with error handling. 

12.5.2 Wakeup Request and Response Commands 

The Wakeup Request and Response commands are only defined for the Active communication mode. 

1 2.5.2.1 Wakeup Request (WUP_REQ) 

This clause defines the Wakeup Request for Attributes WUP_REQ with its parameter bytes. The Initiator sends the 
WUP_REQ to the Target only in the Active communication mode. It shall be applied to reactivate a distinct Target 
device by its NFCID3, which was deactivated by the DSL command. 
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Figure 35: Structure of the WUP_REQ 

1 2.5.2.1 .1 Definition of the WUP_REQ bytes 

CMD 0: Shall be set to (D4). 
CMD 1: WUP_REQ 

The WUP_REQ byte shall specify the command Wake Up for the Initiator device. The value of WUP_REQ shall be 

(02). 

Byte to Byte 9: NFCID3t 

The 10 nfcid3t bytes shall be defined as the random identifier of the Target. For the WUP_REQ command the Initiator 
shall send the known NFCID3t random identifier to wake up the Target. 

Byte 10: DID 

The DID byte shall be used for multiple data transport protocol activation with more then one Targets. The range of the 
DID shall be defined between 1 and 14. The value shall be used, if no DID is used during the data transport protocol. 
All other values are prohibited by the present document. The Initiator may assign a different value to the Target, as used 
before the last DSL command. 

12.5.2.2 Wakeup Response (WUP_RES) 

This clause defines the Wakeup Response for attributes WUP_RES. The WUP_RES shall be the response to the 
WUP_REQ and shall be sent by the selected NFCIP-1 Target device. 



CMDO 


CMD1 


ByteO 


(D5) 


(03) 


DID 



Figure 36: Structure of the WUP_RES 
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1 2.5.2.2.1 Definition of the WUP_RES bytes 

CMD 0: Shall be set to (D5). 

CMD 1: WUP_RES 

The WUP_RES byte shall specify the response to the WUP_REQ. The value of WUP_RES shall be (03). 

Byte 0: DID 

The DID byte shall be used for multiple data exchange protocol activation with more then one Targets. The DIDt shall 
have the same value as the DIDi. All other values are prohibited by the present document. 

1 2.5.2.3 Handling of WUP_REQ and WUP_RES 

12.5.2.3.1 Initiator rules 

When the Initiator has sent a WUP_REQ and receives a valid WUP_RES the Initiator shall continue with operation. 

In any other case the Initiator shall retransmit the WUP_REQ before it shall use the deactivation sequence as defined in 
clause 12.7. In case of failure of the deactivation sequence for passive mode it may use the SLP_REQ command as 
defined in clause 11. 1.2. 19 for Passive communication mode at 106 kbps. 

12.5.2.3.2 Target rules 

When the Target has been de-selected by the last command (for the Active communication mode only); and 

a) receives a WUP_REQ with its NFCID3, the Target: 

shall send its WUP_RES; and 

shall disable in order to not receive a subsequent WUP_REQ. 

b) receives any other valid or invalid frame, except a SLP_REQ command for passive communication mode at 
106 kbps, the Target: 

shall ignore the block; and 

shall remain in receive mode. 

12.5.3 Parameter Selection Request and Response Commands 
1 2.5.3.1 Parameter Selection Request (PSL_REQ) 

The Initiator may switch parameters for the subsequent transport protocol using the PSL_REQ command. 



CMDO 


CMD1 


ByteO 


Bytel 


Byte 2 


(D4) 


(04) 


DID 


BRS 


FSL 



Figure 37: Structure of the PSL_REQ 

12.5.3.1.1 Definition of the PSL_REQ bytes 

CMD 0: Shall be set to (D4). 

CMD 1: PSL_REQ 

The PSL_REQ byte shall specify the command Parameter Selection for the Initiator device. The value of PSL_REQ 
shall be (04). 

Byte 0: DID 

The DID shall be similar to the DID defined during ATR or WUP. 
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Figure 38: Coding of the BRS byte 

bit 7 and bit 6: Shall be set to ZERO. 

bit 5 to bit 3: Bit duration of Initiator to Target. 

bit 2 to bit 0: Bit duration of Target to Initiator. 

Table 22: Coding of DRI and DSI 
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Byte 2: FSL 

The FSL byte defines the maximum value for the Frame Length. 
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Figure 39: Coding of FSL bytes 

bit 7 to bit 2: Shall be set to all ZERO. 
bit 1 and bit 0: Length Reduction value. 

Table 23: Definition of LR 



LR 


LENmax 


00 


Only Byte to Byte 83 is valid in the Transport Data 


01 


Only Byte to Byte 127 is valid in the Transport Data 


10 


Only Byte to Byte 191 is valid in the Transport Data 


11 


Only Byte to Byte 255 is valid in the Transport Data 



1 2.5.3.2 Parameter Selection Response (PSL_RES) 

The definition of the frame structure of PSL_RES shall be as follows. 
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Figure 40: Structure of PSL_RES 
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12.5.3.2.1 Definition of the PSL_RES bytes 

CMDO: Shall be set to (D5). 

CMDl: PSL_RES 

The PSL_RES byte shall specify the command Parameter Selection response for the Target device. The value of 
PSL_RES shall be (05). 

Byte 0: DID 

The DID shall be the same as the DID defined during ATR or WUP. 

1 2.5.3.3 Handling of PSL_REQ and PSL_RES 

12.5.3.3.1 Initiator rules 

The Initiator may change protocol parameters by sending the PSL_REQ to the Target. After reception of a valid 
PSL_RES, the Initiator: 

shall change the framing to the format, which is defined in clause 12.1; and 

shall continue with operation. 

In any other case the Initiator may retransmit the PSL_REQ before it shall use the deactivation sequence as defined in 
clause 12.7. In case of failure of deactivation sequence it may use the SLP_REQ command as defined in 
clause 11.2.1.27 for the Passive communication mode. 

12.5.3.3.2 Target rules 

When the Target has received a ATR_REQ, sent its ATR RES; and 

a) receives a valid PSL_REQ, the Target: 

shall send its PSL_RES; 

shall disable the PSL_REQ (stop responding to received PSL_REQ); 

shall change all parameters to the defined values, which are specified in clause 12.5.3; and 

shall remain in receive mode. 

b) receives an invalid frame, the Target: 

shall ignore the block; 

shall disable the PSL_REQ (stop responding to received PSL_REQ); 

shall remain with the current framing; and 

shall remain in receive mode. 

c) receives a valid frame, except a PSL_REQ, the Target: 

shall disable the PSL_REQ (stop responding to received PSL_REQ); 
shall remain with the current framing; and 
shall continue operation. 
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12.6 Data Exchange Protocol 

12.6.1 Data Exchange Protocol Request and Response 

12.6.1 .1 Data Exchange Protocol Request (DEP_REQ) and Response (DEP_RES) 

The protocol shall be half-duplex protocol supporting block oriented data transmission with error handling. For data, 
which does not fit in one frame a chaining mechanism is defined Format of the protocol frame shall be as follows: 

Transport Data field 

CMDO I CMP 1 I ByteO | Byte 1 | Byte 2 | Byte 3 | Byte 4 | ... | Byte n ~| 
Data Exchange Protocol Header 



CMP I CMP 1 I PFB I [DID] | [NAD] | 

Transport data bytes 



I Data byte | Data byte 1 | ... | Data byte n \ 
Figure 41 : Definition of the protocol frames 

In information interchange, the content of the payload of the Transport Data Field requires agreement between the 
interchanging parties. 

1 2.6.1 .1 .1 Definition of the Data Exchange Protocol Header bytes 

CMDO: 

If the CMDl is DEP_REQ then the CMDO shall be set to (D4). 

If the CMDl is DEP_RES then the CMDO shall be set to (D5). 

CMD 1: DEP_REQ 

The DEP_REQ bytes specify the command for the data exchange protocol for the Initiator device. The value of the 
DEP_REQ shall be (06). 

CMD 1: DEP_RES 

The DEP_RES bytes specify the command for data exchange for the Target device. The value of the DEP_RES shall be 

(07). 

Byte 0: PFB 

The PFB byte shall contain bits to control the data transmission and error recovery. The PFB byte is used to convey the 
information required controlling the transmission. The data exchange protocol defines three fundamental types of pdus: 

Information pdus to convey information for the application layer. 

ACK/NACK pdus to convey positive or negative acknowledgements. An ACK/NACK pdu never contains a 
data field. The acknowledgement relates to the last received block. 

Supervisory pdus to exchange control information between the Initiator and the Target. Two types of 
supervisory pdus are defined. 

Timeout extensions containing a 1 byte long data field. 

Attention containing no data field. 

The coding of PFB depends on its type and is defined in the following definitions. 
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Definition of the Information pdu: 
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Figure 42: Coding of the information pdu 

bit 7 to bit 5: Shall be set to all ZEROs. 

bit 4: If bit set to ONE then it indicates Multiple Information chaining activated. 

bit 3: If bit set to ONE then it indicates NAD available. 

bit 2: If bit set to ONE then it indicates DID available. 

bit 1 and bit 0: PNI packet number information. 

The Packet Number Information (PNI) counts the number of packet send by the Initiator to the Target and vice versa 
starting by 0. These bytes are used for error detection during the protocol handling. 

Definition of ACK/NACK pdu: 
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Figure 43: Coding of the ACK/NACK pdu 

bit 7: Shall be set to ZERO. 
bit 6: Shall be set to ONE. 
bit 5: Shall be set to ZERO. 

bit 4: If bit set to ONE then it indicates NACK, otherwise ACK. 
bit 3: If bit set to ONE then it indicates NAD available, 
bit 2: If bit set to ONE then it indicates DID available, 
bit 1 and bO: PNI packet number. 
Definition of the Supervisory pdu (Attention-Target Present, Timeout extensions): 
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Figure 44: Coding of the supervisory pdu 

bit 7: Shall be set to ONE. 

bit 6 and bit 5: shall be set to ZERO. 

bit 4: If ATTENTION then set to ZERO. If TIME-OUT_EXTENTION then set to ONE. 

bit 3: If bit set to ONE then it indicates NAD available. 

bit 2: If bit set to ONE then it indicates DID available. 
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bit 1 and bO: Shall be set to ZERO. 
Byte 1: DID 

The DID byte shall be the same as defined during activation of the protocol. 

Byte 2: NAD 

The NAD byte is reserved to build up and address different logical connections on both the Initiator and the Target 
device. Bit 7 to bit 4 code the logical address of the Initiator, bits 3 to code the logical address of the Target. The 
following definitions shall apply for the usage of the NAD. 

The NAD shall only be used for the data exchange protocol. 

When the Initiator uses an NAD, the Target shall also use an NAD. 

If MI bit is set, the NAD shall only be transmitted in the first frame. 

The Initiator shall never use the NAD to address two different Targets. 

Byte 3 to Byte n: User data bytes 

The data field shall contain the transported data and is optional. When present, it conveys either application data or 
status information. The length of the data field is calculated by subtracting the mandatory and optional send bytes of the 
data exchange transport header from the length byte and additionally subtracting one. 

1 2.6.1 .2 Handling of Pdu number information 

12.6.1.2.1 Initiator rules 

The PNI of the Initiator shall be initialized for each Target with all ZEROs. 

When an information or acknowledge pdu with an equal PNI is received, the Initiator shall increment the current PNI 
for that Target before optionally sending a new frame. 

12.6.1.2.2 Target rules 

The PNI of the Target shall be initialized with all ZEROs. 

When an information or acknowledge pdu with an equal PNI was received the Target shall send its response with this 
PNI and shall increment the PNI afterwards. 

1 2.6.1 .3 Handling of Blocks 

12.6.1.3.1 General rules 

The first pdu shall be sent by the Initiator. 

When a data pdus indicating more information is received the pdu shall be acknowledged by an ACK pdu. 

Supervisory pdus are only used in pairs. A Supervisory Request shall always be followed by a Supervisory Response. 

12.6.1.3.2 Initiator rules 

When an invalid pdu was received a NACK pdu shall be sent (except in the case of DSL or RLS). 

When a timeout occurs, an attention command shall be sent (except a NACK has been sent before). 

When a timeout occurs and a NACK has been sent before, the NACK shall be retransmitted. 

When an ACK pdu is received, if its pdu number is equal to the current PNI of the Initiator, the chaining shall be 
continued. 
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If the DSL_REQ is not answered by a valid DSL_RES the DSL_REQ may be retransmitted or the Target command 
ignored. 

12.6.1.3.3 Target rules 

The Target is allowed to send an RTO pdu instead of a data pdu. 

When a data pdu not containing chaining is received it shall be acknowledged by a data pdu. 

When an NACK pdu is received, if the PNI is equal to the PNI of the previous sent pdu, the previous block shall be 
re-transmitted. 

When an erroneous pdu is received the Target shall not answer but stay in same State. 

When a Supervisory pdu coding an attention command is received, the Target shall respond sending a supervisory 
attention pdu response. 



1 2.6.2 Response timeout extension 



The response timeout extension shall only be used by the Target. When a Target needs more time to process the 
received block from the Initiator than defined in RWT, it shall use a supervisory pdu using response timeout extension 
request. A response timeout extension request contains 1 byte long data field. The definition of the byte is shown in 
figure 45. 
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Figure 45: Coding of Response timeout extension byte 

bit 7 and bit 6: Shall be set to ZERO. 

bit 5 to bit 0: RTOX value. 

For RTOX the values and 60 to 63 are RFU. For all other values the intermediate RWTjf^j shall be calculated by the 
following formula: 

RWTjNT = RWT X RTOX 

The RWTjj^j starts after the Initiator has sent its RTOX response to the Target. In case RWTjj^j exceeds RWTjy;^^, 
RWT]y[^^ shall be used. The RWTjj^^ is valid until the next frame has been received by the Initiator. 



1 2.6.3 Attention - Target present 



The Initiator shall send the attention command to the Target to ensure the Target is still in field for passive mode or to 
be able to detect a Target loss during multi-activation. This command shall not change the current State of the Target. 

The Target shall respond to a valid Attention Request sending an attention command containing the identical data field 
to the Initiator. 

If the Target receives an incorrect pdu it shall not respond and shall stay in the same State. 



12.6.4 Protocol operation 



After the activation sequence the Target shall wait for a block as only the Initiator has the right to send. After sending a 
block, the Initiator shall switch to receive mode and wait for a block before switching back to transmit mode. The 
Target may transmit blocks only in response to received blocks. After responding, the Target shall return to the receive 
mode. 

The Initiator shall not initiate a new pair of Request/Response until the current pair of Request/Response has been 
completed or if the frame waiting time is exceeded without response. 
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12.6.5 Multi Activation 

The Multi-Activation feature allows the Initiator to hold several Targets active simultaneously. It allows switching 
directly between several Targets without needing additional time for deactivation of a Target and activation of another 
Target. 

For an example of Multi- Activation see table 25. The Initiator needs to handle a separate package number information 
for each activated Target. 

Table 25: Multi Activation 



Initiator Action 


Status Target 1 


Status Target 2 


Status Target 3 


Choose active mode 








Activate Target 1 with DID=1 


Selected (1) 


Sense 


Sense 


Any communication with DID=1 


Selected (1) 


Sense 


Sense 










Activate Target 2 with DID=2 


Selected (1) 


Selected (2) 


Sense 


Any communication with DID=1 ,2 


Selected (1) 


Selected (2) 


Sense 










Activate Target 3 with DID=3 


Selected (1) 


Selected (2) 


Selected (3) 


Any communication with DID=1 ,2,3 


Selected (1) 


Selected (2) 


Selected (3) 










Deactivation Sequence with DID=1 


Sleep 


Selected (2) 


Selected (3) 


Any communication with DID=2,3 


Sleep 


Selected (2) 


Selected (3) 










Deactivation Sequence with DID=2 


Sleep 


Sleep 


Selected (3) 


Any communication with DID=3 


Sleep 


Sleep 


Selected (3) 










Deactivation Sequence with DID=3 


Sleep 


Sleep 


Sleep 











12.6.6 More information (Clnaining) 

The chaining feature allows the Initiator or Target to transmit information that does not fit in a single block, by dividing 
the information into several blocks. Each of those blocks shall have a length less than or equal to the maximum frame 
size (LEN^jAx)- 

The chaining bit in the PFB of a protocol frame control the chaining of frames. Each frame with the chaining bit set 
shall be acknowledged by an ACK pdu. 

The chaining feature is shown in figure 46 using a 16 bytes long string transmitted in three blocks. 
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Send 



Receive 



0123456 789ABC DEF 



Answer 



PFB 

(10) 



0123456 



EDC 



PFB 

(40) 



PFB 

(11) 



789ABC 



EDC 



EDC 



PFB 

(41) 



PFB 

(02) 



DEF 



EDC 



S(ACK)o 



S(ACK)i 



EDC 



PFB 

(02) 



Answer 



EDC 



0123456 789ABC DEF 



Answer 



Receive 
Figure 46: More Information (Chaining) 



Send 



12.7 Deactivation of the protocol 



After exchange of data by using the data exchange protocol, the Initiator may apply a deactivation of the data exchange 
protocol. After successful deactivation Initiator and Target shall stay in the initially chosen mode, but the Initiator may 
choose one of the defined bit rates for reactivation. 

The reactivation of Targets is different for passive and active mode and is defined in clause 1 1 .2. 1 . 16 for passive mode 
and in clause 12.5.2 in active mode. 

After successful deactivation the Target shall not respond to subsequent ATR_REQ commands. 

The RLS_REQ command shall switch the Target back to POWER ON State. See 12.7.2. 1. In this State, the Target shall 
answer to all initial communication schemes and shall also answer to an ATR_REQ. 

12.7.1 Deselect Request and Response command 
1 2.7.1 .1 Deselect request (DSL_REQ) 

This clause defines the deselect command DSL_REQ. The DSL_REQ is sent from Initiator to the Target. 



CMDO 


CMD1 


ByteO 


(D4) 


(08) 


[DID] 



Figure 47: Structure of the DSL_REQ 

12.7.1.1.1 Definition of DSL_REQ bytes 

CMD 0: Shall be set to (D4). 
CMD 1: DSL_REQ 

The DSL_REQ byte specifies the command deselect for the Initiator device. The value of DSL_REQ shall be (08). 
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Byte 0: DID 

The DID shall be the same as defined during ATR or WUP commands. 

1 2.7.1 .2 Deselect response (DSL_RES) 

This clause defines the Deselect Response command DSL_RES. The DSL_RES is the response to the DSL_REQ and is 
sent from the Target to the Initiator. 



CMDO 


CMD1 


ByteO 


(D5) 


(09) 


[DID] 



Figure 48: Structure of the DSL_RES 

1 2.7.1 .2.1 Definition of Deselect Response bytes 

CMD 0: Shall be set to (D5). 

CMD 1: DSL_RES 

The DSL_RES byte specifies the command deselect response for the Target device. The value of DSL_RES shall be 
(09). 

Byte 0: DID 

The DID shall be the same as in DSL_REQ. 

1 2.7.1 .3 Handling of DSL_REQ and DSL_RES 



12.7.1.3.1 



Initiator rules 



When the Initiator has sent a DSL_REQ and received a valid DLS_RES, the Target has been successfully halted. The 
DID assigned to the Target has been released. 

12.7.1.3.2 Target rules 

When the Target has received a DSL_REQ and sent its DSL_RES, the Target: 

shall stay in initially chosen mode; 

shall enable to receive the default bit rates defined in clause 1 1 .2 for the Passive communication mode and in 
clause 11. 3 for the Active communication mode; 

shall remain in receive mode until a valid ALL_REQ is received in passive communication mode at 106 kbps 
or a WUP_REQ is received in active communication mode. 

12.7.2 Release Request and Response commands 
12.7.2.1 Release Request (RLS_REQ) 

This clause defines the release command RLS_REQ. The RLS_REQ is sent from the Target to the Initiator. 



CMDO 


CMD1 


ByteO 


(D4) 


(OA) 


[DID] 



Figure 49: Structure of RLS_REQ 
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12.7.2.1.1 Definition of RLS_REQ bytes 

CMD 0: Shall be set to (D4). 

CMD 1: RLS_REQ 

The RLS_REQ bytes specify the command release for the Initiator device. The value of the RLS_REQ bytes shall be 
(OA). 

Byte 0: DID 

The DID shall be the same as defined in ATR or WUP commands. 

12.7.2.2 Release response RLS_RES 

This clause defines the answer to release command the release response command RLS_RES. The RLS_RES is the 
response to the RLS_REQ sent from the Target to the Initiator. 



CMDO 


CMD1 


ByteO 


(D5) 


(OB) 


[DID] 



Figure 50: Structure of RLS_RES 

12.7.2.2.1 Definition of RLS_RES bytes 

CMD 0: Shall be set to (D5). 

CMD 1: RLS_RES 

The RLS_RES bytes specify the command release for the Target device. The value of the RLS_RES bytes shall be 
(OB). 

Byte 0: DID 

The DID shall be the same as defined in RLS_REQ command. 

1 2.7.2.3 Handling of RLS_REQ and RLS_RES 

12.7.2.3.1 Initiator rules 

When the Initiator has sent a RLS_REQ and received a valid RLS_RES, the Target has been successfully released. The 
Initiator may return to initial State. 

12.7.2.3.2 Target rules 

When the Target has received a RLS_REQ and sent its RLS_RES, the Target shall return to initial State. 
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Annex A (normative): 
CRC calculation 

A.1 CRC for Active and Passive communication mode at 
1 06 kbps 

The frame CRC shall be a frinction of k data bits, which consist of all the data bits in the frame, excluding parity bits, S 
and E, and the CRC it self. Since data is encoded in bytes, the number of bits k shall be a multiple of 8. For error 
checking, the two CRC bytes shall be sent in the Standard Frame, after the bytes and before the E. 

The CRC shall be calculated by the following polynomial. The pre-set value shall be (6363) and the register content 
shall not be inverted after calculation. 

G(x) = x^^ + xl2 + x5 + 1 

For an example of the CRC calculation for the Active and the Passive mode at 106 kbps. See A. 2. 



A.2 Example of CRC calculation at 1 06 kbps 

This example is provided for explanatory purposes and indicates the bit patterns that will exist in the physical layer. It is 
included for the purpose of checking the Passive communication mode implementation at 106 kbps encoding. 

The process of encoding and decoding may be conveniently carried out by a 16-stage cyclic shift register with 
appropriate feedback gates. According to ITU-T Recommendation (ITU-T V.41, Code-independent error control 
system), annex I, figures I-1/V.41 and I-2/V.41 the flip-flops of the register shall be numbered from FFO to FF15. FFO 
shall be the leftmost flip-flop where data is shifted in. FF15 shall be the rightmost flip-flop where data is shifted out. 
Table A. 1 defines the initial content of the register. 

Table A.I : Initial content of 16-stage shift register according to value (6363) 



FFO 


FF1 


FF2 


FF3 


FF4 


FF5 


FF6 


FF7 


FF8 


FF9 


FF10 


FF11 


FF12 


FF13 


FF14 


FF15 





1 


1 











1 


1 





1 


1 











1 


1 



Consequently, FFO corresponds to the msb and FF15 to the Isb. 
Examples of bit patterns that will be transmitted via Standard Frames. 

EXAMPLE 1: Transmission of data, first byte = (00), second byte = (00), CRC appended. 

Calculated CRC = (lEAO). 

First bit transmitted. 



s 


0000 0000 


1 


0000 0000 


1 


0000 0101 


1 


0111 1000 


1 


E 




(00) 


p 


(00) 


p 


(AG) 


p 


(1E) 


p 





Figure A.I : Example 1 for CRC encoding 
Table A.2: Content of 16-stage shift register according to value (1EA0) 



FFO 


FF1 


FF2 


FF3 


FF4 


FF5 


FF6 


FF7 


FF8 


FF9 


FF10 


FF11 


FF12 


FF13 


FF14 


FF15 











1 


1 


1 


1 





1 





1 
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EXAMPLE 2: Transmission of data block, first byte = (12), second byte = (34), CRC appended. 
Calculated CRC = (CF26). 
First bit transmitted. 



s 


0100 1000 


1 


0010 1100 





01100100 





1111 0011 


1 


E 




(12) 


P 


(34) 


P 


(26) 


P 


(CF) 


P 





Figure A.2: Example 2 for CRC encoding 
Table A.3: Content of 16-stage shift register according to value (CF26) 



PRO 


FF1 


FF2 


FF3 


FF4 


FF5 


FF6 


FF7 


FF8 


FF9 


FF10 


FF11 


FF12 


FF13 


FF14 


FF15 


1 


1 








1 


1 


1 


1 








1 








1 


1 






A.3 CRC for Active and Passive communication mode at 
212 kbps and 424 kbps 

The CRC shall be calculated by the CCITT CRC- 16, the scope of which shall include the Length field and the Payload 
field. Calculation in a G(x) shall be defined by: 

G(x) = xl6 + jcl2 + jc5 + 1 

Pre-set value shall be 0. For an example of the CRC calculation for the Active and the Passive mode at 212 kbps and 
424 kbps. See A.4. 

A.4 Example of CRC calculation at 21 2 kbps and 
424 kbps 

The sample Frame is as follows: (00) (00) (00) (00) (00) (00) (B2) (4D) (03) (AB) (CD) (90) (35). 
(B2) (4D) is SYNC. (03) is the length. (AB) (CD) is the user data. (90) (35) is the corresponding CRC. 
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